The \emph{Recommender} uses information from the \emph{User Profile} to query online resources (DBPedia, YouTube, Last.fm) in order to obtain a list of possible recommendations. There are three kinds of recommendations:

\begin{itemize}
\item \textbf{DBPedia Pages} (Static, Dynamic \& Network Recommenders)
\item \textbf{YouTube Videos} (YouTube \& Network Recommender)
\item \textbf{Last.fm Music Bands and Singers} (Last.fm Recommender)
\end{itemize}

An overview of the system is depicted on Figure \ref{fig:recommender-overview}. Detailed descriptions of each recommender apart from the Network Recommender follow in the next sections. For details on how the Network Recommendations work please read the Community Module Section \ref{sec:community}.

\begin{figure}[H]
  \centering
  \includegraphics[width=5in, height=4.3in]{resources/recommender-overview.pdf}
  \caption{Overview of the Recommender System}
  \label{fig:recommender-overview}
\end{figure}

\subsection{Static recommender}

The Static Recommender uses the \emph{User Interests} added by the users (see User Guide Appendix \ref{app-c-adding-interests}) to find DBpedia articles related to them. When a user adds a valid \emph{Interest}, the Static Recommender queries DBPedia to get a list of Subjects (or Categories) that this page falls under. After saving this list in the database, the Static Recommender queries again DBpedia to get all the pages that fall under these Subjects. The urls of these pages are stored on the database to be used later for displaying recommendations.

To retrieve the list of Subjects, a SPARQL query is issued which asks for all the values of the attribute \emph{http://www.w3.org/2004/02/skos/core\#subject} in the DBpedia entry of the interest we want. An example is given in Listing \ref{lst:sparql-poker} that asks for all the subjects of the interest ``Poker". 
\\
\lstset{backgroundcolor=\color{white}}
\lstset{keywordstyle=\color{red}\bfseries\emph}
\begin{lstlisting}[frame=tb, caption=Example of SPARQL query to obtain the Subjects of the interest ``Poker'', label=lst:sparql-poker]
SELECT ?subject
WHERE {
   <http://dbpedia.org/resource/Poker>
   <http://www.w3.org/2004/02/skos/core#subject>
   ?subject
}
\end{lstlisting}

By executing the above SPARQL query we get the list of Subjects shown below (Listing \ref{lst:poker}).

\lstset{backgroundcolor=\color{white}}
\lstset{keywordstyle=\color{red}\bfseries\emph}
\begin{lstlisting}[frame=tb, caption=Example of subjects returned by 
querying with the interest ``Poker", label=lst:poker]
http://dbpedia.org/resource/Category:Poker
http://dbpedia.org/resource/Category:Gambling_games
http://dbpedia.org/resource/Category:Multiplayer_games
http://dbpedia.org/resource/Category:Anglo-American_playing_card_games
http://dbpedia.org/resource/Category:Comparing_card_games
\end{lstlisting}

To obtain a list of recommendations from the above subjects we query DBpedia again, with each of the Subjects and we get a list of DBPedia pages that fall under each subject. An example SPARQL query is given below (Listing \ref{lst:sparql-anglo-american}) which gives all the Anglo-American card games known to DBpedia, like Blackjack, Cribbage, Top Trumps etc.

\lstset{backgroundcolor=\color{white}}
\lstset{keywordstyle=\color{red}\bfseries\emph}
\begin{lstlisting}[frame=tb, caption=SPARQL query used to get recommendations from the category ``Anglo-American\_playing\_card\_games", label=lst:sparql-anglo-american]
SELECT DISTINCT ?x WHERE {
   ?x
   <http://www.w3.org/2004/02/skos/core#subject>
   <http://dbpedia.org/resource/Category:Anglo-American_playing_card_games>
}
\end{lstlisting}

The recommendations we get from each Subject are stored in the database to minimise the number of times we query DBpedia. This leads to better performance and user experience.

\subsection{Dynamic recommender}

\subsubsection{Goals}

The \emph{Dynamic Recommender} deals with the changing interests of the user. When a user provides us with feedback about a particular page (see Section \ref{feedback}), we need a way to retrieve recommendations related to the pages they liked. We also need to take into consideration how much they like this new interest. By \emph{``liking"} a page for Michael Jackson once, does not necessarily mean that they like every pop singer.

\subsubsection{First approach}

An approach to this was to parse the semantic information given in each liked DBpedia page, use the pre-defined ontologies and try to extract important information about the page. This approach turned out to be very complicated and limiting. It  is very complex because each page contains many different ontologies and selecting \emph{``meaningful"} ones would be very hard. It is limiting because we would have to pre-define a list of ontologies that we know that would affect the user's profile, but this would exclude a huge amount of other ontologies with useful information.

\subsubsection{Our approach}

Our approach is simpler and more generalised. Each time a user likes a page, we update their profile using all the page information with a very simple algorithm (see Dynamic Profile in Section \ref{sec:dyn-profile}). 

Figure \ref{fig:dynamic-rec-like-it} visualises this process.

\begin{figure}[H]
  \centering
  \includegraphics[width=5in]{resources/dynamic-rec-like-it.pdf}
  \caption{What happens when a user likes a DBpedia page}
  \label{fig:dynamic-rec-like-it}
\end{figure}

Now, when we want to get further recommendations, we get the most frequent properties that appear in the user's profile and we query DBpedia to find pages that include these frequent properties. The results we get, are stored on the database to decrease the number of calls to DBpedia and are displayed to the user on demand (see Displaying Recommendations Section \ref{} below). 

Figure~\ref{fig:dynamic-rec-query} depicts the recommendation process.

\begin{figure}[H]
  \centering
  \includegraphics[width=5in]{resources/dynamic-rec-query.pdf}
  \caption{Retrieving Dynamic Recommendations}
  \label{fig:dynamic-rec-query}
\end{figure}

\subsubsection{Example}

This is an example taken from a test user that \emph{``liked"} \emph{Johann Sebastian Bach} (http://en.wikipedia.org/wiki/Johann\_Sebastian\_Bach) and \emph{Wolfgang Amadeus Mozart} (http://en.wikipedia.org/wiki/Wolfgang\_Amadeus\_Mozart). Initially the user's profile was empty. After the user \emph{``liked"} these two pages, their profile now holds a list of \emph{134} properties. The most frequent properties (frequency = 2) are listed in Table \ref{tbl:composers} below.

\begin{table}[ht]
	\centering
	\caption{Most frequent properties in the user Profile}
	\label{tbl:composers}
	\footnotesize
    \begin{tabular}{ | l | l |}
    \hline
    \textbf{Attribute} & \textbf{Value} \\ \hline \hline
    http://www.w3.org/1999/02/22-rdf-syntax-ns\#type & http://xmlns.com/foaf/0.1/Person \\ \hline
    http://www.w3.org/1999/02/22-rdf-syntax-ns\#type & http://dbpedia.org/class/yago/GermanComposers\#type \\ \hline
	http://www.w3.org/1999/02/22-rdf-syntax-ns\#type & http://dbpedia.org/class/yago/ComposersForViolin \\ \hline
	http://www.w3.org/2004/02/skos/core\#subject & http://dbpedia.org/resource/Category:German\_composers \\ \hline
	http://www.w3.org/2004/02/skos/core\#subject & http://dbpedia.org/resource/Category:Organ\_improvisers \\ \hline
    \end{tabular}
\end{table}

The Dynamic Recommender used these frequent properties to query again DBpedia and found another \emph{32} entries related to these two composers. A sample of the entries are shown in Table \ref{tbl:composer-recs} below.

\begin{table}[ht]
	\centering
	\caption{5 out of 32 recommendations returned by the Dynamic Recommender}
	\label{tbl:composer-recs}
	\small
    \begin{tabular}{  l  l }
    \textbf{Attribute} & \textbf{Value} \\ \hline \hline
    Antonio Vivaldi & 			http://www.wikipedia.org/wiki/Antonio\_Vivaldi \\
	George Frideric Handel & 	http://www.wikipedia.org/wiki/George\_Frideric\_Handel \\
	Ludwig van Beethoven &		http://www.wikipedia.org/wiki/Ludwig\_van\_Beethoven \\
	Robert Schumann &			http://www.wikipedia.org/wiki/Robert\_Schumann \\
	Johannes Brahms &			http://www.wikipedia.org/wiki/Johannes\_Brahms \\
    \end{tabular}
\end{table}

\subsubsection{Removing old dynamic recommendations}

As we mentioned in the previous section, the dynamic recommendations are stored in the database, in order to be displayed at a later stage without having the user to wait for them to get generated. As the user continues \emph{``liking"} pages, new recommendations are added. The issue we faced here was that old recommendations kept on being recommended. This turned out to be a major problem. As users might lose interest in a subject, there was no way to avoid the old recommendations from being recommended. To solve this, each time the user \emph{``likes"} a page, to update their profile we get the most frequent properties to retrieve the new list of recommendations and remove all the old entries (that don't appear in our new list) from the database.

\subsubsection{Further improvements}
\label{sec:dynamic-rec-further-improvments}

An improvement still needs to be made for when selecting the most frequent properties. If many properties have the same frequency, there is no way to order them and select a subset to use for querying DBpedia\footnote{Querying with too many properties would result in a vast and very broad range of pages}. An idea was to use timestamps. Each time the frequency of a property gets increased, update the timestamp associated with it. This way, we would be able to select the most frequent properties with the most recent timestamp.

\subsection{YouTube \& Last.fm recommenders}
\label{sec:networkrecs}

A good software engineering practice mandates the use of modular programming to make the system separable in modules. This technique, allows designers to extend the system easily and to make the design process more adaptive \cite{modular_design} without changing its core functionality.

The system is designed in a \emph{modular} way, that allows us to easily introduce new kinds of recommendation engines. A new recommender can easily query the \emph{User Profile} to retrieve a user's \emph interests and dynamically created properties. It is, therefore, very easy to retrieve a list of keywords and use them for recommending other kinds of resources. Figure \ref{fig:new-recommender} below illustrates the pattern that a new kind of recommender could follow.

\begin{figure}[H]
  \centering
  \includegraphics[width=5in]{resources/new-recommender.pdf}
  \caption{How a new kind of recommender can be added easily to our system}
  \label{fig:new-recommender}
\end{figure}

YouTube and Last.fm are two examples that we implemented using this pattern. Each of them receives a list of keywords from the Profile, and probabilistically chooses either a random subset of them or a random subset of the user's interests. The reason we chose to implement this probabilistically is to have a diversity of queries that represent both the user's expressed interests and the dynamic profile that builds up with their \textit{``likes''}.

\subsection{Displaying DBpedia recommendations}

\subsubsection{Requirements}

Each time a user wants to get some recommendations, a subset of them needs to be selected from the database. This subset of recommendations needs to meet the following requirements:

\begin{enumerate}
\item Most relevant recommendations
\item Recommendations that haven't been recommented yet. If all were recommended, the ones that were displayed the least amount of times.
\item Must contain both Static and Dynamic Recommendations (even if one of them is empty)
\end{enumerate}

\subsubsection{Our approach}

Having these requirements in mind, each time we display a recommendation, we increment a counter that tells us how many times it was displayed. Then the next time we want to display them, we will get the ones with the smallest counter. This satisfies the 2nd requirement.

For satisfying the 3rd requirement, the proportion of Static \& Dynamic recommendations that will be displayed is proportional to the total number of Static \& Dynamic recommendations stored on the database for this user. That means that if 60\% of the available recommendations are Static then if you ask for 10 recommendations, 6 of them will be Static and 4 of them will be Dynamic.

The 1st requirement is harder to satisfy. How do we choose which ones are the most relevant to the user? How do we define the most relevant? For the case of Static Recommendations we didn't find a way to define the most relevant so we randomly pick among the least displayed recommendations. For the Dynamic Recommendations, it is logical to assume that the most recently added recommendations should be displayed, so the user would get a feeling that his liked page did make a change on the recommendation he receives. The way we designed our system (without timestamps) doesn't let us know this. But the order in which they are stored in the database (their unique id) is relevant to the order they were added in the database. Using this, when we retrieve the list of Dynamic Recommendations we give preference to the ones with the biggest unique id.

\subsubsection{Further improvements}

The system could be redesigned to be working with timestamps. Each recommendation could have 2 timestamps: when it was first added, when it was last displayed. These timestamps would help us improve the selection of recommendations by displaying more relevant and fresh recommendations.

Another improvement would be to generalise the algorithm for selecting which DBPedia recommendations to display and make it available for other kind of recommenders to use it, ex. Amazon Books recommender etc.
